dynamic maven versioning to drive releases using git tags #25
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hey @ericcwlaw
CI Friendly Versioning, based on git tags
I'm proposing to change:
to
This will change the behaviour of the software to build jar files as
x.x-SNAPSHOT
by default, but when you tag the software (or usemvn package -Drevision=1.2.3
), then it will create a release. It has the advantage that the git tag and a specific version are tied to each other and you clearly know what are "releases" and what are snapshots.So you won't actually have to do any manual releases, since the CI pipeline, in my example GitLab, can do these releases for you.
This is based on Maven's "CI Friendly Versioning"
Releasing Maven Artifacts to GitLab Registry
Furthermore I updated the GitLab CI pipeline accompanying these changes and releasing the resulting JAR's into the project's GitLab Maven Registry (in my fork). In the future a release to maven-central is desired, but it is more involved. To not make this pull request/review more complex it is not part of this.
Parent Pom
Additionally I added a parent-pom under
system/parent/
to drive deployment configuration.Next steps
The suggested changes could potentially break some of your builds, depending how you include the jars (version numbers etc). Hence we should discuss and verify that these changes are desired and move the project in the direction you want it to go.